The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Mail transfer agents (MTA's) typically receive a large number of email messages from many different senders for delivery to many recipients. The number of email messages can range from hundreds of messages per hour to hundreds of thousands of messages per hour. Because of the increasing problems of the tremendous volume of unsolicited commercial email (i.e., spam) and from a significant percentage of email messages being infected with viruses, administrators of MTA's would like to be able to control the number of connections to the MTA's and to manage the delivery of the many email messages to in an easy and efficient manner as part of the efforts to deal with spam and virus infected email messages.
However, traditional approaches for managing the connections to an MTA from different senders treat each sender separately. For example, if the administrator of the MTA has observed that a particular Internet Protocol (IP) address has been sending a large amount of spam to the MTA, the administrator can configure the MTA to refuse to accept incoming connections from the particular IP address. Over time, the administrator will likely identify a large number of IP addresses that send spam to the MTA, and for each such IP address, the administrator must separately configure the MTA to reject the incoming connections from the offending IP addresses. The same situation can arise for email messages from particular IP addresses that are identified as being infected with a virus.
Due to the growing proliferation of spam and viruses, the administrator is faced with the dilemma of either constantly monitoring the flow of email messages for spam and virus infected email messages and continually reconfiguring the MTA to reject incoming connections from the offending IP addresses, or the administrator can limit the time spent in such efforts to dealing with just the biggest sources of such offending email messages while letting other smaller sources go unchecked.
Also, traditional approaches for controlling the flow of email messages from different senders through an MTA provide two options: allow everything from a sender or allow nothing from a sender. For example, the administrator of the MTA can create a “whitelist” of IP addresses from which email messages should never be rejected, and a “blacklist” of IP addresses from which email messages should never be accepted. Taken together, these types of lists can be termed an “all or nothing” approach.
However, a problem with the “all or nothing” approach is that both the whitelist and the blacklist are over inclusive. For example, if the administrator of the MTA adds a particular IP address to the whitelist, and then the server for that IP address is used by the owner of an email account on that server to send out thousands of spam email messages, that spam will always be allowed by the MTA, and the users served by that MTA will be inundated with the spam. Similarly, if the user blacklists a particular IP address, any bona fide users associated with that IP address that do not send spam would not be able to get any email messages through the MTA.
Another problem with traditional approaches for managing email messages at an MTA is in dealing with directory harvest attacks in which a sender, typically a spammer, floods the MTA with a large number of email messages addressed to many recipients. The recipient email addresses are from a large list of email addresses that typically include many common and randomly generated usenames. By flooding the MTA with the large number of email messages and keeping track of which recipient addresses are accepted by the MTA and which recipient addresses result in rejection of the email message by the MTA and usually a message rejection message (i.e., a “bounce” message) that tells the sender that the MTA rejected the email message, the spammer can effectively reconstruct a directory of valid recipient email addresses for the MTA. The reconstructed directory can then be used for subsequent spam campaigns or may even be used in a virus attack.
One traditional approach for dealing with directory harvest attacks is to configure the MTA to never generate a bounce message. As a result, the spammer may believe that all the recipient email addresses are valid and will include all such email addresses in the reconstructed directory. But the later use of that reconstructed directory will be very ineffective because the directory will typically contain many more invalid recipient email addresses than valid recipient email addresses. On the other hand, if the spammer notices that none of the attempted recipient addresses are generating any bounces, the spammer will know that the MTA has been configured to not generate bounce messages, and the spammer will not pursue the directory harvest attack further because the MTA is not allowing the spammer to determine which email addresses are valid and which are invalid.
One problem in configuring the MTA to not generate any bounce messages is that some email messages received by the MTA should generate a bounce message back to the sender to let the sender know that the email address is invalid. For example, if a bona fide sender simply mistypes an email address or uses an email address that in the past was valid but currently is not valid (e.g., the email address is for an ex-employee), the administrator of the MTA would generally want the sender of such email messages to know that they used an invalid email address so that the sender can try again or make other efforts to determine what the problem is with the invalid email address. If the MTA does not generate a bounce message, then bona fide senders that make simple typographical mistakes in addressing email messages will never know of the invalid email addresses and thus will be led to incorrectly believe that the email messages were delivered to the intended recipients. This could be particularly problematic if the sender is a customer of the company served by the MTA.
Another problem with configuring the MTA to not generate any bounce messages is that the administrator of the MTA has no way of knowing whether a directory harvest attack has occurred. For example, if the administrator learns that a spammer is conducting a directory harvest attack, and then the administrator reconfigures the MTA to stop generating bounce messages, the administrator has no way of knowing when the spammer gives up the attack, so that the administrator can turn the bounce messages back on. If the administrator turns the bounce messages back on while the attack is still underway, the spammer will be able to identify more valid email addresses. However, if the administrator waits for a while to turn the bounce messages back on, or in the extreme case never turns the bounce messages back on, then the administrator will never know when the directory harvest attack ends, nor would the administrator be aware of any subsequent directory harvest attacks that the administrator would usually want to be made aware.
Based on the foregoing, it is desirable to provide improved techniques for managing the flow of email messages to an MTA that can enable the administrator of the MTA to more efficiently and effectively deal with different senders of undesired email messages. Furthermore, there is a need for approaches for controlling the number of connections to an MTA, for controlling the flow of email messages through the MTA, and for dealing with directory harvest attacks.